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1 Introduction 


This specification is part of the NFC Forum documentation about tag types that an NFC Forum 
Device needs to support in NFC Forum Reader/Writer Mode. 


This specification documents how an NFC Forum Device SHALL operate an NFC Forum Type 1 
Tag. This is not a specification of the NFC Forum Type 1 Tag itself. 


1.1 Objectives 


The purpose of this specification is to document the requirements and to specify, with a set of 
rules and guidelines, the NFC Forum Device operation and management of the Type 1 Tag. 


This specification assumes that the Collision Detection and Device Activation activities have 
been performed as documented in the [ACTIVITY], [DIGITAL], and [ANALOG] specifications 
and these have been completed up to the level of making a single Type 1 Tag identifier (UID) 
available. 


This specification also defines the data mapping and how the NFC Forum Device detects, reads, 
and writes NDEF data into the Type 1 Tag in order to achieve and maintain interchangeability 
and interoperability. 


1.2 Applicable Documents or References 


[ACTIVITY] NFC Activity Specification, 
Version 1.0, 
NFC Forum 


[ANALOG] NFC Analog, 

In progress, 

NFC Forum 
[DIGITAL] NFC Digital Protocol, 


Version 1.0, 
NFC Forum 


[ISO/IEC 14443] Identification cards — Contactless integrated circuit cards — Proximity 
cards 


Includes: 


e [ISO/IEC 14443-1:2008], Identification cards — Contactless 
integrated circuit cards — Proximity cards — Part 1: Physical 
characteristics 


e [ISO/IEC 14443-2:2010], Identification cards — Contactless 
integrated circuit cards — Proximity cards — Part 2: Radio frequency 
power and signal balance 


e [ISO/IEC 14443-3:2001], Identification cards — Contactless 
integrated circuit cards — Proximity cards — Part 3: Initialization and 
anticollision 
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e [ISO/IEC 14443-3:2001/Amd.1], Identification cards -- Contactless 
integrated circuit(s) cards -- Proximity cards -- Part 3: Initialization 
and Anti-collision, 1 February 2001 with Amendment 1: Bit rates of 
fc/64, fc/32 and fc/16, 15 June 2005; Amendment 3: Handling of 
reserved fields and values, 22 March 2006; and Corrigendum 1: 
Amendment 1 - Corrigendum, 29 August 2006 


e [ISO/IEC 14443-4:2008], Identification cards — Contactless 
integrated circuit cards — Proximity cards — Part 4: Transmission 
protocol 


ISO/IEC 


[NDEF] NFC Data Exchange Format, 
Version 1.0, 
NFC Forum 
[RFC2119] Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, 
S. Bradner, 
March 1997, 
Internet Engineering Task Force 


1.3 Administration 


The NFC Type 1 Tag Specification is an open specification supported by the Near Field 
Communication Forum, Inc., located at: 


401 Edgewater Place, Suite 600 
Wakefield, MA, 01880 


Tel.: +1 781-876-8955 
Fax: +1 781-610-9864 


http://www.nfc-forum.org/ 


The NFC Devices Technical Working Group maintains this specification. Comments, errors, and 
other feedback can be submitted at http://www.nfc- 
forum.org/apps/group_public/document.php?document_id=9774&wg_abbrev=chairs. 


1.4 Name and Logo Usage 


The Near Field Communication Forum’s policy regarding the use of the trademarks NFC Forum 
and the NFC Forum logo is as follows: 


e Any company MAY claim compatibility with NFC Forum specifications, whether a member 
of the NFC Forum or not. 


e Permission to use the NFC Forum logos is automatically granted to designated members only 
as stipulated on the most recent Membership Privileges document, during the period of time 
for which their membership dues are paid. 


e Member's distributors and sales representatives MAY use the NFC Forum logo in promoting 
member's products sold under the name of the member. 
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e The logo SHALL be printed in black or in color as illustrated on the Logo Page that is 
available from the NFC Forum at the address above. The aspect ratio of the logo SHALL be 
maintained, but the size MAY be varied. Nothing MAY be added to or deleted from the 
logos. 


e Since the NFC Forum name is a trademark of the Near Field Communication Forum, the 
following statement SHALL be included in all published literature and advertising material in 
which the name or logo appears: 


NFC Forum and the NFC Forum logo are trademarks of the Near Field Communication 
Forum. 


1.5 Intellectual Property 


The Type 1 Tag Operation Specification conforms to the Intellectual Property guidelines 
specified in the NFC Forum's Intellectual Property Rights Policy, as outlined in the NFC Forum 
Rules of Procedure. These documents are available on the NFC Forum website. 


1.6 Special Word Usage 


The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, 
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL.” in this 
document are to be interpreted as described in [RFC2119]. 


1.7 Convention and Notations 


1.7.1 Representation of Numbers 
The following conventions and notations apply in this document unless otherwise stated. 


e Binary numbers are represented by strings of digits 0 and 1 shown with the most significant 
bit (msb) left and the least significant bit (Isb) right; ^b" is added at the end. 


Example: 11110101b 


e Hexadecimal numbers are represented using the numbers 0 - 9 and the characters A — F; an 
“h” is added at the end. The most significant byte (MSB) is shown on the left and the least 
significant byte (LSB) on the right. 


Example: F5h 


e Decimal numbers are represented as is (without any trailing character). 
Example: 245 


1.8 Abbreviations 


The abbreviations as used in this document are defined in Table 1. 


Table 1: Abbreviations 


Abbreviation Description 

ALL REQ ALL NFC-A REQuest 
CC Capability Container 
CE Command End 
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CRC Cyclic Redundancy Check 

HRO Header ROM byte 0 

IEC International Electrotechnical Commission 
ISO International Organization for Standardization 
Isb least significant bit 

LSB Least Significant Byte 

msb most significant bit 

MSB Most Significant Byte 

NDEF NFC Data Exchange Format 
NFC Near Field Communication 

NMN NDEF Magic Number 

UID Unique IDentifier 

URI Uniform Resource Identifier 
RALL Read All Command 

READ Read Command 

RFU Reserved for Future Use 

RID Read ID Command 

RTD Record Type Description 

ROM Read Only Memory 

RWA Read Write Access 

SENS REQ Sense Request Command Type A 
TLV Tag, Length, Value 

TMS Tag Memory Size 

UID Unique IDentification 

VNo Version Number 

WRITE-E Write with Erase Command 
WRITE-NE Write no Erase Command 
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1.9 Glossary 


This section defines all relevant terms and acronyms used in this specification. 


NFC Forum Device 
A device that supports the following Modus Operandi: Initiator, Target and 
Reader/Writer. It may also support Card Emulation Mode. 

NFC Forum Reader/Writer Mode 


In NFC Forum Reader/Writer Mode, the NFC Forum Device starts the Master/Slave 
Communication and sends commands to an NFC Forum Tag or contactless card. The 
communication for this mode is abbreviated as RW. 


Type 1 Tag Operation Specification 


Page 5 


Memory Structure and Management 


2 Memory Structure and Management 


2.1 General 
The NFC Forum Type 1 Tag utilizes a simple memory model. 


[RQ T1T MEM, 001] There SHALL be two memory model mappings depending on the 
memory size of the tag: 


e Static memory structure applies for a tag with physical memory size equal to 120 bytes, 
e Dynamic memory model applies for a tag with physical memory size larger than 120 bytes. 


[RQ TIT MEM, 002] The memory SHALL be considered as being divided into blocks 
containing 8 bytes each. 


Each block is numbered from 0 to 14 (Eh) for static memory structure or from 0 to k for dynamic 
memory structure. The number associated to a block is called the ‘block number’. 


The 8 bytes inside each block are numbered from 0 to 7, where byte 0 is the LSB and byte 7 is the 
MSB of the block. 


For the complete tag address space, byte 0 of block 0 corresponds to ByteAddr = 0 as the LSB. 


Byte 7 of block Eh for static memory structure or byte 7 of block k for dynamic memory structure 
indicates the MSB. 


Unless otherwise stated, within this document the byte ordering when defining packets and 
messages follows the little-endian byte order. 


The next two sections described in detail the two memory structures. 
2.2 Static Memory Structure 


2.2.1 Memory Map 
The static memory map of the NFC Forum Type 1 Tag, with HRO = 11h, is shown in Figure 1. 


EEPROM Memory Map 


Byte-1 Byte-2 Byte-3 Byte-4 Byte-5 Byte-6 Lockable 


UID-1 UID-2 UID-3 UID-4 UID-5 UID-6 Locked 


Datal Data2 Data3 Data4 Data5 Data6 Data7 


Data9 Data10 Data11 Data12 Data13 Datal4 Data15 


Data17 Data18 Data19 Data20 Data21 Data22 Data23 


Data25 Data26 Data27 Data28 Data29 Data30 Data31 
Data33 Data34 Data35 Data36 Data37 Data38 Data39 


Data41 Data42 Data43 Data44 Data45 Data46 Data47 


Data49 Data50 Data51 Data52 Data53 Data54 Data55 
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EEPROM Memory Map 


Byte-0 Byte-1 Byte-2 Byte-3 Byte-4 Byte-5 Byte-6 Byte-7 Lockable 
(LSB) (MSB) 


Data56 Data57 Data58 Data59 Data60 Data61 Data62 Data63 


Data64 Data65 Data66 Data67 Data68 Data69 Data70 Data71 
Data72 Data73 Data74 Data75 Data76 Data77 Data78 Data79 


Data80 Data81 Data82 Data83 Data84 Data85 Data86 Data87 


Data88 Data89 Data90 Data91 Data92 Data93 Data94 Data95 


Reserved 


Lock/Reserved 


Reserved for internal use 
User Block Lock & Status 
OTP bits 
Figure 1: Static Memory Map of the Base NFC Forum Type 1 Tag 


2.2.2 Header ROM Format 


The NFC Forum Type 1 Tag includes two bytes of fixed header ROM called HRO and HR1, as 
shown in Figure 1. These are not individually addressable by a Read command. 


The contents are automatically included in the response packet to certain commands. 


[RQ_T1T_MEM_003] HRO Upper nibble = 0001b SHALL determine that it is a Type 1, NDEF 
capable tag. 


[RQ_T1T_MEM_004] HRO Lower nibble = 0001b SHALL determine static memory map. 


[RQ_T1T_MEM_005] HRO Lower nibble Z 0001b SHALL determine the dynamic memory 
map. 


[RQ_T1T_MEM_006] HR1 = xxh is undefined and SHALL be ignored. 


2.2.3 UID Format 

Block 0 is reserved for the read-only Unique Identification (UID) number. 
Byte 7 is reserved for future use. 

Byte 6 is the manufacturer's identification code. 


Bytes 5, 4, 3, 2, 1, 0 are unique numbers. 


2.2.4 Main Read/Write Memory Format 
The 12 blocks numbered as 1h to Ch contain 96 bytes of general read/write memory. 


Each block is individually lockable to become read-only by use of the relevant bits within the 
lock control bytes, as described in Section 2.2.6. 


2.2.5 Block Dh 


The block numbered as Dh is read-only and reserved for internal use. 
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2.2.6 Lock Control/Status Bytes 

Bytes 0 and 1 of block Eh function as the lock controls for the various memory blocks. 
They operate in a bit-wise one-time-programmable fashion. 

Figure 2 shows the factory default settings for a Type 1 Tag with static memory map. 


The individual locking bits can be set to 1b by using a suitable bit mask via a standard write 
command to the relevant bytes in block number Eh. 


This process is irreversible: if one bit of the lock bytes is set to 1b, it cannot be changed back to 
Ob again. 


LOCK-0 LOCK-1 
(Byte 0 of Block Eh) (Byte 1 of Block Eh) 


BLOCK-2 

BLOCK-0 Locked 

BLOCK-E Locked 

BLOCK-C 
Unlocked 

BLOCK-8 


Unlocked 


0b 
1b 
1b 
0b 


Ob 


igure 2: Lock Control/Status Bytes 


2.2.7 OTP Bytes 


Bytes 2 — 7 of block Eh are allocated as One Time Programmable (OTP) bits and are not defined 
for NFC Forum purposes. 


2.3 Dynamic Memory Structure 


2.3.1 Dynamic Memory Map 


[RQ T1T MEM. 007] The NFC Forum Type 1 Tag with dynamic memory map is indicated by 
HRO = 1yh, where y # 1. In this case, a capability container shall be included in the tag memory 
containing information about the physical memory size. See Section 6.1.4. 


An example of the dynamic memory map representation of the NFC Forum Type 1 Tag with HRO 
= 1yh, where y Z 1, is shown in Figure 3. 


EEPROM Memory Map 


Byte-0 Byte-1 Byte-2 Byte-3 Byte-4 Byte-5 Byte-6 Byte-7 Lockable 
(LSB) (MSB) 


UID-0 UID-1 UID-2 UID-3 UID-4 UID-5 UID-6 Locked 


Data0 Datal Data2 Data3 Data4 Data5 Data6 Data7 


Data8 Data9 Data10 Data11 Data12 Data13 Data14 Data15 


Data16 Data17 Data18 Data19 Data20 Data21 Data22 Data23 


Data24 Data25 Data26 Data27 Data28 Data29 Data30 Data31 
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EEPROM Memory Map 


Byte-0 Byte-1 Byte-2 Byte-3 Byte-4 Byte-5 Byte-6 Byte-7 Lockable 
(LSB) (MSB) 


Data32 Data33 Data34 Data35 Data36 Data37 Data38 Data39 Yes 


Data40 Data41 Data42 Data43 Data44 Data45 Data46 Data47 


Data48 Data49 Data50 Data51 Data52 Data53 Data54 Data55 
Data56 Data57 Data58 Data59 Data60 Data61 Data62 Data63 


Data64 Data65 Data66 Data67 Data68 Data69 Data70 Data71 
Data72 Data73 Data74 Data75 Data76 Data77 Data78 Data79 


Data80 Data81 Data82 Data83 Data84 Data85 Data86 Data87 


Data88 Data89 Data90 Data91 Data92 Data93 Data94 Data95 


Reserved 


Lock/Reserved LOCK- LOCK- 
0 1 


Lock/Reserved LOCK- LOCK- 
2 3 


Data96 Data97 Data98 Data99 Data100 Data101 Data102 Data103 


Data104 Data10 Data106 Data107 Data108 Data109 Data110 Data111 
5 


Data112 Datal1 Data114 Data115 Data116 Data117 Data118 Data119 
3 


Data120 Data12 Data122 Data123 Data124 Data125 a126 Data127 
1 


Data128 Data12 Data130 Data131 Data132 Data133 a134 Data135 
9 


Data136 Data13 Data138 Data139 Data140 Data141 a142 Data143 
7 


Data144 Data14 Data146 Data147 a148 a149 a150 Data151 
5 


Data152 Data15 Data154 Data155 a156 a157 a158 Data159 
3 


Data160 Data16 Data162 Data163 a164 a165 a166 Data167 
1 


Data168 Data16 Data170 Data171 a172 a173 a174 Data175 
9 


Data176 Data17 Data178 Data179 a180 a181 a182 Data183 
7 


Data184 Data18 Data186 Data187 a188 a189 a190 Data191 
5 


Lock/Reserved : LOCK- LOCK- LOCK-x | LOCK-x | LOCK-x | LOCK-x | LOCK-x LOCK-x 
x x 


Lock/Reserved LOCK- LOCK- LOCK-x | LOCK-x | LOCK-x | LOCK-x | LOCK-x LOCK-x 
x x 


Figure 3: Example Dynamic Memory Map of NFC Forum Type 1 Tag 


In Figure 3, each memory block is numbered from 0 to k. 


[RQ_T1T_MEM_008] Dynamic lock bytes and reserved bytes might be located at any byte 
address in between or at the end of the data area starting from block OFh. 
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[RQ T1T MEM, 009] Compared to the static memory structure, the dynamic memory structure 
SHALL contain configuration information to describe the details of dynamic lock bits and to 
identify reserved memory areas in the data area using the Lock Control TLV and the Memory 
Control TLV. 


The capability container and TLV data areas are not shown in Figure 3. For an example, refer to 
A.2. 
2.3.2 Dynamic Memory Reserved Bytes 


[RQ T1T MEM, 010] These bytes belong to Reserved memory areas and SHALL be ignored / 
jumped over during read and write parsing operations of NFC Forum data. 


[RQ TIT MEM 011] The location of Reserved bytes SHALL be identified by one or more 
Memory Control TLV blocks, as described in Section 2.4. 

2.3.8 Dynamic Memory Lock Bytes 

A tag with a dynamic memory structure contains two kinds of lock bytes: 

e Static lock bytes as specified in Section 2.2.6. 

e Dynamic memory lock bytes. 

[RQ TIT MEM 012] The position of the dynamic memory lock bytes within the tag memory 
MAY change. 

2.3.4 Dynamic Memory Area 

The additional dynamic memory area is located from block Fh onward. 


The available data area for the dynamic memory structure is contained from block 1 up to the last 
block of the memory, including the 96 bytes of the static memory structure and excluding static 
and dynamic lock bytes and reserved bytes. 


Addressing of memory blocks is relative to and includes Block 0. 
The available data area capacity in bytes is equal to: 
8- (k —3) - DynamicLockBytes — DynamicReservedBytes 


This calculation includes the data area of the static memory structure equal to 96 bytes and 
discounts blocks 0, Dh, and Eh. 


2.4 TLV Blocks 


2.4.1 Format 
A TLV block consists of one to three fields: 


e T (tag field or T field) identifies the type of the TLV block and consists of a single byte 
encoding a number from 00h to FFh. The tag values 04h to FCh and FFh are reserved for 
future use by the NFC Forum. 


e L (length field or L field) provides the size in bytes of the value field. It has two different 
formats composed of one or three bytes. 


[RQ_T1T_MEM_013] The NFC Forum device SHALL understand both length field formats. 
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Figure 4 shows the two different length field structures. 


[RQ TIT MEM 014] However, depending on the tag field value, the length field may not be 
present. 


One byte format: 


[RQ T1T MEM. 015] The NFC Forum device SHALL use the one byte format to code the 
length of the value field between 00h and FEh bytes. 


[RQ T1T MEM. 016] The NFC Forum device SHALL interpret this byte as a cardinal if the 
value is between 00h and FEh. 


[RQ T1T MEM 017] If it contains FFh, the NFC Forum device SHALL interpret the value as 
flag that specifies that the length field is composed of more than one byte. 


Three consecutive bytes format: 


[RQ TIT MEM 018] The NFC Forum device SHALL use this format to code the length of the 
value field between 00FFh and FFFEh bytes. 


[RQ TIT MEM. 019] The first byte is assumed to be a flag equal to FFh, indicating that two 
more bytes are present. The NFC Forum device SHALL interpret the two more bytes as a word. 


[RQ T1T MEM, 020] The NFC Forum device SHALL interpret this word as a cardinal if the 
value is between OOFFh and FFFEh. 


The value FFFFh is reserved for future use (RFU). 


00- 
1 byte format 
OOFF- 
FFFE 3 bytes format 


Figure 4: Length Field Formats 


e V (value field or V field). If the length field is equal to 00h or there is no length field, the 
value field is not present (i.e., the TLV block is empty). If there is a length field and it 
indicates a length N bigger than zero (N70), the value field consists of N consecutive bytes. 


Table 2 lists the TLV blocks defined by this document that are described in the following 
sections. 
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Table 2: Defined TLV blocks 


2.4.2 Location 


TLV Block Name Tag Field Value Short Description 

NULL TLV 00h [RQ TIT MEM 021] May be used for padding 
of memory areas and the 
NFC Forum Device 
SHALL ignore this 

Lock Control TLV 01h Defines details of the lock bytes 

Memory Control TLV 02h Identifies reserved memory areas 

NDEF Message TLV 03h Contains the NDEF message 

Proprietary TLV FDh Tag proprietary information 

Terminator TLV FEh Last TLV block in the data area 


[RQ T1T MEM, 022] The NFC Forum device SHALL recognize and interpret the TLV blocks 
in a specific order inside the data area according to the following rules: 


e NDEF Message TLVs and Proprietary TLVs are present after all Lock Control TLVs and 


Memory Control TLVs. 


e If present, the Terminator TLV is the last TLV block on the Type 1 Tag. 


NULL TLV and Terminator TLV are the only TLV blocks that are 1 byte long (e.g., composed of 
only the Tag field. See the NOTE below). 


[RQ TIT MEM, 023] NFC Forum Devices SHALL ignore and jump over those TLV blocks 
that make use of reserved Tag field values. 


[RQ TIT MEM, 024] To jump over a TLV block with reserved Tag field values, the NFC 
Forum device SHALL read the length field to understand the length of the value field. 


NOTE Future definitions of TLV blocks composed of only the Tag field are not backward 
compatible with this NFC Forum specification. 


2.4.3 Lock Control TLV 


[RQ T1T MEM, 025] The Lock Control TLV can be present inside the Type 1 Tag. An NFC 
Forum Device SHALL be able to read and process it. 


The Lock Control TLV provides control information about the lock areas where the dynamic lock 


bytes are located. 


Each Lock Control TLV indicates a single lock area. More lock areas are indicated using more 
Lock Control TLV blocks. The encoding of the 3 TLV fields of the Lock Control TLV is as 


follows: 
e T isequalto Oth. 
e L isequalto 03h. 


e V iscomposed of 3 bytes that uniquely identify the position and the size of the lock area 
and the number of bytes locked by each bit of the dynamic lock bytes. The 3 bytes are 


encoded as follows: 
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e Position, MSB. It codes the position inside the tag memory of the lock area. The position 
byte consists of 2 parts (to calculate the bytes address from the position byte, see the 
equation below): 


e  PagesAddr. Most significant nibble (4 bits), coded as number of pages (Oh=0...Fh=15) 
and 


e  ByteOffset. Least significant nibble, coded as number of bytes (Oh=0...Fh=15). 


e Size. Middle byte, coded as number of bits (01h=1...FFh=255, 00h-256). It indicates the 
size in bits of the lock area (i.e., the number of dynamic lock bits). If the number of 
dynamic lock bits is not a multiple of 8, they are stored inside the dynamic lock bytes as 
explained in the description of the default setting of the dynamic lock bits. 


e Page control, LSB. The page control provides general control information: the size in 
bytes of a page and the number of bytes that each dynamic lock bit is able to lock. Page 
control byte is split up into two nibbles of 4 bits each: 


e  BytesPerPage: Least significant nibble, coded as 2" (Oh=RFU, 1h=1...Fh=15). It 
indicates the number of bytes per page. 


e BytesLockedPerLockBit: Most significant nibble, coded as 2" (Oh-RFU, 
1h=1...Fh=15). It indicates the number of bytes that each dynamic lock bit is able to 
lock. 


[RQ TIT MEM, 026] The NFC Forum device SHALL calculate the byte address (ByteAddr) of 
the beginning of the lock area as follows: 


ByteAddr = PageAddr - 2?"***!** + ByteOffset 


The ByteAddr is calculated from the beginning of the overall memory of the tag (i.e., Byte 0 of 
Block 0 is indicated by ByteAddr equal to 0). 


The ByteAddr is used to read and write the relative lock area using the appropriate tag access 
commands. The page definition has nothing to do with the block definition used by tag access 
commands. 


An example of the BytesLockedPerLockBit is: If the memory area locked by a single dynamic 

lock bit is 8 bytes, then the BytesLockedPerLockBit is equal to 3 (i.e., 2P"'esLockedPertockBit 3-9 

bytes). 

NOTE The Lock Control TLV might be skipped if a Type 1 Tag is in READ-ONLY state. 
Lock Control TLV blocks can be replaced by Reserved Memory Control TLV 
indicating the same memory areas for Type 1 Tag in READ-ONLY state. 


2.4.4 Reserved Memory Control TLV 


[RQ T1T MEM, 027] The Reserved Memory Control TLV can be present inside the Type 1 
Tag and an NFC Forum Device SHALL be able to read and process it. 


It provides control information about the location and the size of the reserved byte area. 


[RQ T1T MEM, 028] If the vendor delivers the Type 1 Tag in the READ-ONLY state, the 
NFC Forum device MAY use the Reserved Memory Control TLV to indicate control information 
for a mix of reserved and lock areas. 


Type 1 Tag Operation Specification Page 13 


Memory Structure and Management 


The encoding of the 3 TLV fields of the Reserved Memory Control TLV is: 
e T isequalto 02h. 
e L isequalto 03h. 


e V is composed of 3 bytes that uniquely identify the position and the size of the reserved 
area. The 3 bytes are encoded as follows: 


e Position, MSB. It codes the position inside the tag of the reserved area. The Position byte 
consists of 2 parts (to calculate the bytes address from the position byte, see below): 


e  PagesAddr. Most significant nibble, coded as number of pages (Oh=0...Fh=15) 
e  ByteOffset. Least significant nibble, coded as number of bytes (Oh=0...Fh=15) 


e Size. Middle byte, coded as number of bytes (1h71, FFh=255, Oh=256). It indicates the 
size in bytes of the reserved area. 


e Partial Page Control, LSB. The partial page control provides the size in bytes of a page. It 
is split up into two nibbles of 4 bits each: 


e Least significant nibble (BytesPerPage nibble), coded as 2" (Oh=RFU, 
1h-1...Fh-15). It indicates the number of bytes per page. 


e Most significant nibble is RFU. 


[RQ_T1T_MEM_029] The NFC Forum device SHALL calculate the byte address (ByteAddr) of 
each reserved area as follows: 


ByteAddr = PageAddr - 2™®:®™9° + ByteOffset 


The ByteAddr is calculated from the beginning of the overall memory of the tag (i.e., Byte 0 of 
Block 0 is indicated by ByteAddr equal to 0). 


The page definition has nothing to do with the block definition used by tag access commands. 


2.4.5 NDEF Message TLV 


The NDEF Message TLV is always present inside the Type 1 Tag. It stores the NDEF message 
inside the Value field (see [NDEF]). 


[RQ T1T MEM, 030] The NFC Forum device SHALL be able to read and process the first (or 
mandatory) NDEF message. 


Further NDEF Message TLV blocks can be present. 
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The encoding of the 3 TLV fields of the NDEF Message TLV is: 
e T isequalto 03h. 

e Lis equal to the size in bytes of the stored NDEF message. 
e V stores the NDEF message (see [NDEF]). 


An empty NDEF Message TLV is defined as an NDEF Message TLV with L field equal to 00h 
and no V field (i.e., no NDEF message is present in the V field; see [NDEF]). 


A non-empty NDEF Message TLV can contain either empty or non-empty NDEF messages. 


2.4.6 Proprietary TLV 
The Proprietary TLV contains proprietary information. 


[RQ T1T MEM. 031] A Type 1 Tag contains zero, one, or more Proprietary TLV. The NFC 
Forum device MAY ignore the data contained in this TLV block. 


The encoding of the 3 TLV fields of the Proprietary TLV is: 
e Tis equal to FDh. 
e Lis equal to the size in bytes of the proprietary data in the Value field. 


e V contains any proprietary data. 


2.4.7 NULL TLV 
The NULL TLV can be used for padding of the data area. 


[RQ T1T MEM, 032] A Type 1 Tag contains zero, one, or more NULL TLV. The NFC Forum 
device SHALL ignore and jump over this TLV block. 


The NULL TLV is composed of 1 byte tag field. 
The encoding of the T field of the NULL TLV is: 


e T isequalto 00h. 
e L isnot present. 


e V isnot present. 


2.4.8 Terminator TLV 


[RQ T1T MEM, 033] The Terminator TLV can be present inside the Type 1 Tag and an NFC 
Forum device SHALL be able to read and process it. 


The Terminator TLV is the last TLV block in the data area. Terminator TLV is composed of 1 
byte tag field. 


The encoding of the T field of the Terminator TLV is: 
e T isequalto FEh. 
e L isnot present. 


e V isnot present. 
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3 RF Interface 


[RQ T1T RFI 001] The RF interface of the NFC Forum Device required for operation in 
NFC Forum NFC Forum Reader/Writer Mode is defined in [ANALOG]. 
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4 Framing and Transmission Handling 


4.1 Frame Formats 

The frame formats used by the NFC Forum device to operate with the NFC Forum Type 1 Tag 
are given in [DIGITAL]. 

4.2 Transmission Handling 


[RQ T1T FTH 001] The transmission handling of the commands/responses used for 
initialization, collision detection, device activation activities, and selection of the Type 1 Tag by 
the NFC Forum device are defined in [DIGITAL]. 


Command/responses for operation according to this specification are given in Section 5. 
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5 Command Set 


5.1 State Diagram 
The basic state chart for operation of the NFC Forum Type 1 Tag is shown in [DIGITAL]. 


5.2 Tag Command and Response Set 


5.2.1 Static Memory Model 


[RQ T1T CSE 001] Commands used for the Type 1 Tag with the static memory map SHALL 
generate a response comprised of a number of bytes as shown in Table 3. 


Table 3: Command-Response Byte Count (Static Memory Model) 


Command Command bytes Response bytes 
RALL 9 124 
READ 9 4 
WRITE-E 9 4 
WRITE-NE 9 4 


Details of the sequence of Command and Response bytes for the operation of the Type 1 Tag 
with the static memory map are shown in Table 4. 


Table 4: Command-Response Summary (Static Memory Model) 


Command-Response Summary Table 


[RQ T1T CSE 002] Greyed-out frames are dummy frames - their data content SHALL be 00h 


Command Response 


00h 


00h 


ocociod|ocdciocda 
c cicc|ioc|woc 


U 
1 
U 
1 
U 
1 
U 
1 


U 
2 
U 
2 
U 
2 
U 
2 


[RQ T1T CSE 003] Atwo-byte CRC, as defined in [DIGITAL], SHALL be appended to the 
end of commands and responses as shown in Table 4. 


5.2.2 Dynamic Memory Model 


The additional Command-Response bytes required for access to the dynamic memory model are 
shown in Table 5 and Table 6. 
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Table 5: Command-Response Byte Count (Dynamic Memory Model) 


Command Command bytes  |Response bytes 
RSEG 16 131 
READ8 16 11 
WRITE-E8 16 11 
WRITE-NE8 16 11 


Table 6: Command-Response Summary (Dynamic Memory Model) 


5.3 Command Format 


5.3.1 Command List 


Command 


RALL 


Table 7: List of Commands (Static Memory Model) 


Command Code (7-bits) 


b6 


b4 


b3 


Comment 


Command 
RSEG |ADDS |00h 00h 00h 00h 00h 00h 00h 00h UID |UID |UID |UID |CRC1 |CRC2 
0 1 2 3 
READ8 |ADD8 |00h 00h 00h 00h 00h 00h 00h 00h UID |UID |UID |UID |CRC1 |CRC2 
0 1 2 3 
WRITE |ADD8 |DAT |DAT |DAT |DAT |DAT |DAT |DAT |DAT |UID |UID |UID |UID |CRC1 |CRC2 
-E8 0 1 2 3 4 5 6 7 0 1 2 3 
WRITE |ADD8 |DAT |DAT |DAT |DAT |DAT |DAT |DAT |DAT |UID |UID |UID |UID |CRC1 |CRC2 
-NE8 0 1 2 3 4 5 6 7 0 1 2 3 
Response 
ADDS |DATO |DAT1 |DAT2 |DAT3 |DAT4 |DATS5 | DAT6 | DAT7 DAT 127 |CRC1 | CRC2 
ADD8 | DATO |DAT1 |DAT2 |DAT3 |DAT4 |DATS5 | DAT6 | DAT7 |CRC1 |CRC2 
ADD8 | DATO |DAT1 |DAT2 |DAT3 |DAT4 |DATS5 | DAT6 | DAT7 |CRC1 |CRC2 
ADD8 | DATO | DAT1 |DAT2 |DAT3 |DAT4 |DATS5 | DAT6 | DAT7 |CRC1 |CRC2 


(all commands are independent) 


Read All (all bytes) 


READ 


Read (a single byte) 


WRITE-E 


|Write-with-erase (a single byte) 


WRITE-NE 


[RQ T1T CSE 004] 


IWrite-no-erase (a single byte) 


code bit patterns other than those commands shown in Table 7. 


Type 1 Tag Operation Specification 
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Table 8: List of Additional Commands (Dynamic Memory Model) 


Command Code (7-bits) 


Comment 


Command msb (all commands are independent) 


b6 b4 
RSEG Read Segment 


READ8 Read (eight bytes) 


WRITE-E8 IWrite-with-erase (eight bytes) 


WRITE-NE8 IWrite-no-erase (eight bytes) 


The Type 1 Tag with the dynamic memory model will ignore any command code bit patterns 
other than those commands shown in Table 7 and Table 8. 

5.3.2 Command-Response Format 

[RQ T1T CSE 005] 8-bit operand and data frames, as defined in [DIGITAL], SHALL follow 
all commands listed in Table 7 and Table 8. 

5.3.3 Address Operand 


[RQ T1T CSE 006] The format of the address operand ‘ADD’ for the READ, WRITE-E, and 
WRITE-NE commands of the Type 1 Tag with static memory model SHALL be as shown in 
Table 9. 


Table 9: Format of Address Operand ADD (Static Memory Structure) 


Address operand ‘ADD’ 


Block = select one of blocks 0h — Eh 
Byte = select one of bytes 0 — 7 


msb 


b8 b7 b6 


Ob Static Block 


[RQ T1T CSE 007] The format of the address operand ‘ADDS’ for the RSEG command of 
the Type 1 Tag with the dynamic memory model SHALL be as shown in Table 10. 


Table 10: Format of Address Operand ADDS (Dynamic Memory Model) 


Address operand ‘ADDS’ 


Segment = select one of the Segments 0h — Fh 


msb 


b8 b7 


Segment 
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[RQ T1T CSE 008] The format of the block address operand ‘ADD8’ for the READS, 
WRITE-E8, and WRITE-NE8 commands of the Type 1 Tag with the dynamic memory model 
SHALL be as shown in Table 11. 


Table 11: Format of Address Operand ADD8 (Dynamic Memory Model) 


Address operand ‘ADD8’ 


Block = select one of the 8-byte blocks 00h — FFh 


msb 


b8 b7 


Global Block 


5.3.4 CRC 
[RQ T1T CSE 009] The CRC operation SHALL be as defined in [DIGITAL]. 


5.3.5 UID Echo 


[RQ T1T CSE 010] The NFC Forum Device in NFC Forum Reader/Writer Mode SHALL 
execute a single Type 1 Tag selection feature as defined in [DIGITAL]. 


[RQ_T1T_CSE_011] This SHALL result in provision of a single identifier comprised of the 
lower four bytes of UID. 


[RQ TIT CSE 012] All subsequent commands used to communicate with this Type 1 Tag for 
operation as described in this specification SHALL include these lower four bytes of UID as part 
of the proprietary Read and Write commands. 


[RQ T1T CSE 013] Ifthe four lower bytes of UID do not match, then the Type 1 Tag will 
halt operation and remain in ‘READY’ state, as defined in [DIGITAL], waiting for the next valid 
command. 


5.4 Command Details 


5.4.1 Detailed Timing 
The detailed command timing of a single bit period is defined in [DIGITAL]. 


5.4.2 Timing Definitions 


The timing definitions for commands covered by this document are given in Table 12 below. 
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Table 12: Timing Definitions 


Timing & Description Definitions (used in the command sequence descriptions) 


Description Specification 


Reader-Reader Data Delay Minimum: 


The time between the end of the last pause of a frame | e >28 us when last bit was 1 
transmitted by the Reader/Writer and the first pause 
of the next frame to be transmitted by the : 
Reader/Writer Max numi; 
. None 


e 723 ys when last bit was 0 


Typel tag Device Response Delay FDT timing from [ISO/IEC 14443], where n: 


(Frame Delay Time) . For RALL and READ: n-9 
The time between the end of the last pause e. For WRITE E: n=554 
transmitted by the Reader/Writer and the first 


: eat : 3 e For WRITE_NE: n=281 
modulation edge within the start bit transmitted by ith tol f isita 1 l , 
the Type 1 Tag With tolerance for Digital & Analogue elements of + 6.5 


lock cycles (13.56MHz). 
(taken from the FDT definition in [ISO/IEC 14443) | “lock cycles ( a 


Reader Response Delay [ISO/IEC_14443]1172/fc = 86 ps 
Delay time Type 1 Tag to Reader/Writer (i.e., the 
time between the last modulation transmitted by the 
Type 1 Tag and the first gap transmitted by the 
Reader/Writer) 


CE Command End 


UID-echo The four least significant UID bytes from block 0 
(LSB first) 


Table 13: FDT Timing Calculations 


Command FDThpit-1 = 128n + 84 FDTyi.o = 128n + 20 
RALL and READ 1236/fc ~ 91 us 1172/fc = 86 us 
WRITE-E 70996/fc = 5236 us 70932/fc = 5231 us 
WRITE-NE 36052/fc = 2659 us 35088/fc = 2654 us 
NOTE The diagrams in the following sections do not show lead-in, start, and end of frame 
bits. 


5.5 SENS REQ and ALL REQ 
These commands are defined in [DIGITAL]. 


5.6 Read Identification (RID) 
This command is defined in [DIGITAL]. 
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5.7 Read All Blocks 0-Eh (RALL) 

3-0 d HW dH H d od 

ea fere ERR Wee Wo Wee CER | EA E NAA 
| 


UID -echo 
Frame from lhe lag. aaa eee eee ee ae HRI vino [| uit DATA CRC2 |---}------------ 


Header metal- 
mast RON 


Frames to the tag 


B lock- E 
Continue Byte-7 


command 


Device decision 


Figure 5: RALL Command/Response Diagram 
The RALL command reads-out the two Header ROM bytes and all of the static memory blocks 0- 
Eh. 


[RQ T1T CSE 014] The Command frame, then Address frame, Data-byte frame, UID-echo 
frames (with UID data received from previous RID command), and CRC frames SHALL be sent 
by the NFC Forum Device in NFC Forum Reader/Writer Mode to the tag. 


[RQ T1T CSE 015] However, the Address and Data-bytes SHALL be set to zero. 


If the UID and CRC are valid, the HRO and HR1 bytes followed by the contents of memory 
blocks 0-Eh and the frame CRC bytes will be sent back to the NFC Forum Device in NFC Forum 
Reader/Writer Mode. 


As a pre-condition, this command requires that the tag be in the READY state and afterward, the 
tag remains in READY state. 


5.8 Read Byte (READ) 


RROD 


ar UL | 
Franestotnetag — (Urn [ee [n 


: A. 
x 
4 

T 


— 
U ID -echo 


Frame from the tag 


Im mediately 
change to 
CE status 


Continue 
command 


Device decision 
Figure 6: READ Command/Response Diagram 
[RQ T1T CSE 016] The READ command relates to a single EEPROM memory byte within 


the static memory model area of blocks 0-Eh. The byte address (Block number and Byte number), 
as defined in Table 9, SHALL be sent with the command. 
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[RQ T1T CSE 017] The command frame, then Address frame, Data-byte frame, UID-echo 
frames (with UID data received from previous RID command) and CRC frames SHALL be sent 
by the NFC Forum Device in NFC Forum Reader/Writer Mode to the tag. 


[RQ T1T CSE 018] However, the Data-byte SHALL be set to zero. 


If the CRC and UID are valid, the requested memory data byte is read from memory. The 
Address, followed by the read data byte and the frame CRC bytes, will be sent back to the NFC 
Forum Device in NFC Forum Reader/Writer Mode. 

As a pre-condition, this command requires that the tag be in the READY state and afterward, the 
tag remains in READY state. 


5.9 Write-Erase Byte (WRITE-E) 


RRDD RRDD RRDD RRDD 


D RRDD RRDD RRDD RRDD 


Frames to the tag 


Frame from the lad. — Mannes go epee eean 


Immediately change to 
CE status (do not start 
programme sequence) 


CE 


Device decisions 


Continue 
Command 


Block = 1 to C 


& 
BLOCK - Locked 
? 


Figure 7: WRITE-E Command/Response Diagram 


[RQ T1T CSE 019] The WRITE-E (Write-Erase) command relates to an individual memory 
byte within the static memory model area of blocks 0-Eh. The target byte address (Block number 
and Byte number), as defined in Table 9, SHALL be sent with the command. 


This command performs the *normal' erase-write cycle (i.e., it erases the target byte before it 
writes the new data). 


If any of BLOCK-0 to BLOCK-D is locked, then WRITE-E is barred from those blocks. 
Additionally, WRITE-E is always barred from Blocks 0, D, and E because these are 
automatically in the locked condition. 


[RQ T1T CSE 020] The Command frame, then Address frame, Data-byte frame, UID-echo 
frames (with UID data received from previous RID command), and CRC frames SHALL be sent 
by the NFC Forum Device in NFC Forum Reader/Writer Mode to the tag. 
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If the UID and CRC are valid (and WRITE-E is not barred), the EE memory erase-write cycle is 
carried out. The byte is then read back from the EE memory. The address, followed by the data 
byte and the frame CRC bytes, are then sent back to the NFC Forum Device in NFC Forum 
Reader/Writer Mode. 


If WRITE-E is barred, the erase-write cycle is skipped—no write operation occurs and the tag 
will enter READY status waiting for a new command. 


As a pre-condition, this command requires that the tag be in the READY state and afterward, the 
tag remains in READY state. 


5.10 Write-No-Erase Byte (WRITE-NE) 


XI 


RRDD RRDD RRDD RRDD RRDD RRDD RRDD DRD 


E gd HW od d I 


Frames to the tag 


UID-echo 


Líamelfom tne tag. exeo ener e a a ec suenecs ene 


Immediately change to 


CE status (do not start 

rogramme sequence 

CRC & UID N prog 4 ) 
Correct? 


Y 


CE 


Device decisions 


Block = 0 orD 
? 


Continue 


lockz 1t 
Command Bue & we 


BLOCK =Locked 
? 


Figure 8: WRITE-NE Command/Response Diagram 


[RQ T1T CSE 021] The WRITE-NE (Write-no-erase) command relates to an individual 
memory byte within the static memory model area of blocks 0-Eh. The target byte address (Block 
number and Byte number), as defined in Table 9, SHALL be sent with the command. 


This command does not erase the target byte before writing the new data, and the execution time 
is approximately half that of the ‘normal’ write command (WRITE-E). Bits can be set but not 
reset (i.e., data bits previously set to a ‘1’ cannot be reset to a *0"). 


The WRITE-NE command has three main purposes: 
e Lock — to set the ‘lock bit’ for a block. 


e OTP - to set One-Time-Programmable bits (bytes 2 — 7 of Block-E), where between one and 
eight OTP bits can be set with a single WRITE-NE command. 


e Afast-write in order to reduce overall time to write data to memory blocks for the first time 
given that the original condition of memory is zero. 
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If any of BLOCK-1 to BLOCK-C are locked, then WRITE-E is barred from that block. 
WRITE-NE is not barred from BLOCK-E to allow setting of lock and OTP bits. 


[RQ T1T CSE 022] The Command frame, then Address frame, Data-byte frame, UID-echo 
frames (with UID data received from previous RID command), and CRC frames SHALL be sent 
by the NFC Forum Device in NFC Forum Reader/Writer Mode to the tag. 


If the UID and CRC are valid (and WRITE-NE is not barred), the EE memory write-no-erase 
cycle is carried out. The byte is then read back from the EE memory. The Address, followed by 
the Data byte and the frame CRC bytes, are then sent back to the NFC Forum Device in NFC 
Forum Reader/Writer Mode. 


If WRITE-NE is barred, the write-no-erase cycle is skipped—no write operation occurs and the 
tag will return to the “READY” state and wait for a new command. 


As a pre-condition, this command requires that the tag be in the READY state and afterward, the 
tag remains in READY state. 


5.11 Locking 


All twelve of the memory blocks 1h to Ch are separately lockable. 
When a block's ‘lock-bit’ is set to a 1, that block becomes irreversibly frozen as ‘read-only’. 
The lock-bits are stored in the Bytes 0 and 1 of BLOCK-Eh. 


[RQ T1T CSE 023] The WRITE-NE command with appropriate data pattern SHALL be used 
by the NFC Forum Device in NFC Forum Reader/Writer Mode to set individual lock-bits. 


A single WRITE-NE command can be used to set between one and eight lock-bits. 


5.12 Read Segment (RSEG) 


The RSEG command reads-out a complete segment of memory. A segment consists of 16 blocks 
(i.e., 128 bytes of memory). 


The command frames to the Type 1 Tag are similar to the RALL command, with the ADD 
replaced by ADDS (Address Segment) to select the required segment with the format as defined 
in Table 10. 


The Command-Response summary is given in Table 6. 


[RQ T1T CSE 024] The Command frame, then Address frame, eight data-byte frames, UID- 
echo frames (with UID data received from previous RID command), and CRC frames SHALL be 
sent by the NFC Forum Device in NFC Forum Reader/Writer Mode to the tag. 


[RQ T1T CSE 025] However, the eight data-bytes SHALL be set to zero. 


If the UID and CRC are valid, then the ADDS, followed by the 128 byte contents of that segment 
and the frame CRC bytes, will be sent back to the NFC Forum Device in NFC Forum 
Reader/Writer Mode. 


As a pre-condition, this command requires that the tag be in the READY state and afterward, the 
tag remains in READY state. 
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5.13 Read 8 Bytes (READS) 


The READ8 command reads-out a block of memory. 


The command frames to the Type 1 Tag are similar to the single byte READ command, with the 
ADD replaced by ADD8 (Address 8) to select the required block with the format as defined in 
Table 11. 


The Command-Response summary is given in Table 6. 


[RQ TIT CSE 026] The Command frame, then Address frame, eight data-byte frames, UID- 
echo frames (with UID data received from previous RID command), and CRC frames SHALL be 
sent by the NFC Forum Device in NFC Forum Reader/Writer Mode to the tag. 


[RQ T1T CSE 027] However, the eight data-bytes SHALL be set to zero. 


If the UID and CRC are valid, then the ADDS, followed by the 8 data-bytes contents read from 
that block and the frame CRC bytes, will be sent back to the NFC Forum Device in NFC Forum 
Reader/Writer Mode. 


As a pre-condition, this command requires that the tag be in the READY state and afterward, the 
tag remains in READY state. 


5.14 Write-Erase 8 Bytes (WRITE-E8) 


The WRITE-E8 command writes with erase to a block of memory. 


The command frames to the Type 1 Tag are similar to the single byte WRITE-E command, with 
the ADD replaced by ADD8 (Address 8) to select the required block with the format as defined in 
Table 11. 


The Command-Response summary is given in Table 6. 


[RQ T1T CSE 028] The Command frame, then Address frame, eight data-byte frames for the 
data to be written, UID-echo frames (with UID data received from previous RID command), and 
CRC frames SHALL be sent by the NFC Forum Device in NFC Forum Reader/Writer Mode to 
the tag. 


If the UID and CRC are valid, then the ADD8, followed by the 8 data-bytes contents just written 
to that block and the frame CRC bytes, will be sent back to the NFC Forum Device in NFC 
Forum Reader/Writer Mode. 


As a pre-condition, this command requires that the tag be in the READY state and afterward, the 
tag remains in READY state. 


5.15 Write-No-Erase 8 Bytes (WRITE-NE8) 


The WRITE-E8 command writes with no erase to a block of memory. 


The command frames to the Type 1 Tag are similar to the single byte WRITE-NE command, with 
the ADD replaced by ADD8 (Address 8) to select the required block with the format as defined in 
Table 11. 


The Command-Response summary is given in Table 6. 
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[RQ T1T CSE 029] The Command frame, then Address frame, eight data-byte frames for the 
data to be written, UID-echo frames (with UID data received from previous RID command), and 
CRC frames SHALL be sent by the NFC Forum Device in NFC Forum Reader/Writer Mode to 
the tag. 


If the UID and CRC are valid, then the ADDS, followed by the 8 data-bytes contents just written 
to that block and the frame CRC bytes, will be sent back to the NFC Forum Device in NFC 
Forum Reader/Writer Mode. 


As a pre-condition, this command requires that the tag be in the READY state and afterward, the 
tag remains in READY state. 


Type 1 Tag Operation Specification Page 28 


NDEF Detection and NDEF Access 


6 NDEF Detection and NDEF Access 
6.1 NDEF Management 


6.1.1 Identification as NFC Forum Type 1 Tag 
The Type 1 Tag has a fixed Header ROM byte called HRO. 


[RQ T1T NDA 001] To identify the Type 1 Tag, the high nibble of HRO SHALL be equal to 
0001b. 


[RQ TIT NDA. 002] When the NFC Forum Device operating in NFC Forum Reader/Writer 
Mode encounters a tag working to the proprietary protocol as used by the Type 1 Tag, then it 
SHALL use this HRO value to identify if the tag is capable of carrying an NDEF message. 


[RQ TIT NDA. 003] The HRO value SHALL be made available from the output of the 
collision detection, device activation, and single identifier activities of the Mode Switch as 
defined in [DIGITAL]. 


6.1.2 Write Permission 


[RQ TIT NDA 004] An NFC Forum Device in NFC Forum Reader/Writer Mode SHALL not 
attempt to write to a tag unless confirmed by HRO = 1xh. This pre-qualification SHALL be used 
to protect accidental writing and corruption of a non-NDEF application tag, such as a transit 
ticket based on an IC operating with the same proprietary protocol but with different HRO value. 


6.1.3 Confirmation of Presence of NDEF Message in Type 1 Tag 


[RQ T1T NDA 005] Although the qualification of the HRO value will have identified the tag 
encountered as a Type 1 Tag and therefore capable of carrying an NDEF message, there may or 
may not be an actual NDEF message present. 


To further qualify that a valid NDEF message is actually present, a Capability Container (CC) 
SHALL be used. 


[RQ TIT NDA. 006] The CC SHALL contain NFC Forum management data. 


[RQ TIT NDA, 007] The CC SHALL be assigned to be in the first four bytes of memory 
block 1. 


6.1.4 Capability Container 


[RQ T1T NDA 008] The CC memory area SHALL not be used to store any application 
related data. 


[RQ T1T NDA 009] Byte 0, when equal to E1h (NDEF Magic Number), SHALL indicate that 
NFC Forum defined NDEF Message data is stored in the data area. 


[RQ T1T NDA 010] Byte 1 SHALL carry the Version Number (VNo) of this document as 
supported by the Type 1 Tag. The most significant nibble (the 4 most significant bits) SHALL 
indicate the major version number, and the least significant nibble (the 4 least significant bits) 
SHALL indicate the minor version number. 


[RQ TIT NDA 011] The VNo may change during the life time of an NFC Forum Type 1 Tag. 


[RQ TIT NDA 012] Byte 2 SHALL indicate the physical tag memory size (TMS) of the Type 
1 Tag as multipliers of (8 bytes) * (n* 1). Examples: 
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e 120 bytes are indicated by OEh 
e 256 bytes are indicated by 1Fh 
e 2048 bytes are indicated by FFh 


[RQ TIT NDA 013] Byte 3 SHALL indicate the read and write access (RWA) capability of 
the CC and data area of the Type 1 Tag. 


[RQ T1T NDA 014] The most significant nibble (the 4 most significant bits) SHALL indicate 
the read access condition: 


e The value Oh indicates read access granted without any security. 
e Any other value is reserved for future use. 


[RQ TIT NDA 015] The least significant nibble (the 4 least significant bits) SHALL indicate 
the write access condition: 


e The value Oh indicates write access granted without any security. 

[RQ TIT NDA. 016] The value Fh indicates no write access granted at all. 

e Any other value is reserved for future use. 

Table 14 shows an example coding of the CC bytes. This example is related to a Type 1 Tag: 
e With NFC Forum defined data (byte 0 = E1h) 


e Supporting version 1.0 (major number 1h, minor number Oh) of the mapping document (byte 
1 = 10h) 


e With 120 bytes of memory size (byte 2 = OEh) 


e With read and write access granted without any security (byte 3 = 00h) 


Table 14: Example Coding of the CC Bytes of Block 1 


Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 
NDEF Version Tag Read/Write Start of TLV and NDEF Message data area 

“Magic Number Memory Access 

Number” Size 

NMN VNo TMS RWA Octet 1 Octet 2 Octet 3 Octet 4 
E1h 10h OEh 00h 


6.2 Version Treatment 


[RQ T1T NDA 017] Byte 1 of the CC contains the Version number (VNo) of this document 


as applied to the storage of NDEF Message data within Type 1 Tag. 


This SHALL be indicated with two numbers: major number version and minor version number. 
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[RQ TIT NDA. 018] The rules for the handling of the different document version numbers 
applied to the Type 1 Tag (called T1VNo) and the one implemented in the NFC Forum device 
(called NFCDevVNo) are explained in the cases shown in Table 15. 


Table 15: Rules for Handling of the Version Number 


No | Version Number Case Handling 
1 Major NFCDevVNo is equal to The NFC Forum device SHALL access the Type 1 
major T1VNo, and Tag and SHALL use all features of the applied 
minor NFCDevVNo is bigger than | mapping document to this Type 1 Tag. 
or equal to minor TIVNo 
2 If major NFCDevVNo is equal to Possibly not all features of the Type 1 Tag can be 
major T1VNo, and accessed. The NFC Forum device SHALL use all its 
minor NFCDevVNo is lower than | features and SHALL access this Type 1 Tag. 
minor T1VNo 
3 If major NFCDevVNo is smaller Incompatible data format. The NFC Forum device 
than major T1VNo cannot understand the Type 1 Tag data. The NFC 
Forum device SHALL reject this Type 1 Tag. 
4 If major NFCDevVNo is bigger The NFC Forum device might implement the 
than major T1VNo support for previous versions of this specification in 
addition to its main version. In case the NFC Forum 
device has the support from previous version, it 
SHALL access the Type 1 Tag. On the contrary, in 
case the NFC Forum device does not have the 
support from the previous version, it SHALL reject 
the Type 1 Tag. 
NOTE Future versions of this specification have to define the allowed actions with an NFC 


Forum Type 1 Tag with a version number lower than the version number of the NFC 
Forum Device (i.e., whether it is allowed to upgrade the tag to the new version). 
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6.3 NDEF Storage 
The data format of the NDEF Message is defined in [DIGITAL ]. 


[RQ T1T NDA 019] The NDEF Message SHALL be stored inside the value field of the 
NDEF Message TLV in the data area of the Type 1 Tag as shown in Figure 9. 


EEPROM Memory Map 


Memory Byte-0 Byte-1 Byte-2 Byte-3 Byte-4 Byte-5 Lockable 
Block (LSB) 


0 UID-0 UID-1 UID-2 UID-3 UID-4 UID-5 Locked 


1 CCO CC1 CC2 CC3 NDEF NDEF 
(NMN) (Vno) (TMS) (RWA) Message | Message 
-E1h =10h =0Eh -00h TLV TLV 
T=03h L=5Ah 


Octet3 Octet4 Octet5 Octet6 Octet7 Octet8 Octet9 Octet10 


Octet11 Octet12 et13 et14 Octet15 Octet16 17 Octet18 


Octet19 Octet20 et21 et22 Octet23 Octet24 25 Octet26 


Octet27 Octet28 29 et30 Octet31 Octet32 33 Octet34 


Octet35 Octet36 37 et38 Octet39 Octet40 41 Octet42 


Octet43 Octet44 45 et46 Octet47 Octet48 49 Octet50 
Octet51 Octet52 53 et54 Octet55 Octet56 57 Octet58 


Octet59 Octet60 61 et62 Octet63 Octet64 65 Octet66 
Octet67 Octet68 69 et70 Octet71 Octet72 73 Octet74 


Octet75 Octet76 77 78 Octet79 Octet80 81 Octet82 


Octet83 Octet84 85 86 Octet87 Octet88 89 Octet90 


Locked 


Reserved for internal use 
User Block Lock & Status 
OTP bits 
Figure 9: Location of NDEF Message 


[RQ_T1T_NDA_020] The TLV and NDEF Message storage SHALL start from byte 4 of 
memory block 1 onward, up to the maximum capacity of the memory. 
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6.4 Life Cycle 


6.4.1 General 


An NFC Forum Type 1 Tag can be classified to exist in several states. The state is reflected by 
the contents of the tag as perceived by the NFC Forum Device in NFC Forum Reader/Writer 
Mode. 


Each state SHALL have its own set of valid operations depending on the current context of the 
NFC Forum Device. By context, it is meant whether the application is expecting to read from a 
tag or expecting to write NDEF message onto a tag. 


The following sections specify the life-cycle relevant to the NFC Forum Type 1 Tag. 


6.4.2 Overview of Life-Cycle States 


[RQ TIT NDA 021] The NFC Forum Device in NFC Forum Reader/Writer Mode SHALL 
interpret the NFC Forum Type 1 Tag to be in one of the following states: INITIALIZED, 
READ/WRITE, and READ-ONLY. 


The state SHALL be reflected by the content of the tag. 


The state transitions are only relevant for NFC Forum Devices, which are capable of writing Type 
1 Tags. 


The states represented in this section are not related to tag command states as shown in 
[DIGITAL]. 
6.4.3 INITIALIZED State 


[RQ_T1T_NDA_022] A Type 1 Tag SHALL be considered to be in INITIALIZED state when 
not in the READ/WRITE or READ ONLY states. 


The Capability container as defined in Section 6.1.4 shall be present in the Initialized state. 


In the case of tags with memory size >120 Bytes (i.e., the Dynamic Memory structure), then the 
Lock Control and Memory Control TLV blocks as defined in Section 2.4 SHALL also be present 
in the Initialized state. 


See the example in A.2. 


6.4.4 READ/WRITE State 


The tag is considered to already contain a valid NDEF message content. It is available for read 
and re-write access. 


[RQ T1T NDA 023] This state SHALL provide the ability to read the NDEF message and also 
to modify it (i.e., completely overwrite the existing NDEF message with a new NDEF message). 


[RQ TIT NDA 024] This state SHALL be reached via the INITIALIZED state. 
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[RQ TIT NDA. 025] A Type 1 Tag SHALL be detected in READ/WRITE state when: 

e CC has byte 0 equal to E1h, and 

e CC has byte 1 with value according to version handling rules of Section 6.2, and 

e CChas byte 3 equal to 00h (read/write access granted), and 

e The data area contains an NDEF Message TLV, and 

e The length field of the NDEF Message TLV is different from zero and equal to the actual 
length of the NDEF message in the value field 

6.4.5 READ ONLY State 


[RQ T1T NDA 026] This state SHALL be reached via the READ/WRITE or INITIALIZED 
state. In this configuration, the CC and the whole data area SHALL be set to read-only. The Type 
1 Tag SHALL stay in READ-ONL Y state for the remaining life cycle. 


[RQ T1T NDA 027] The tag is considered to contain a valid NDEF message and be available 
for read-only access. It cannot be deleted or overwritten with a new NDEF message. 


[RQ TIT NDA. 028] A Type 1 Tag SHALL be detected in READ-ONLY state when: 
e CC has byte 0 equal to E1h, and 

e CChas byte 1 with value according to version handling rules of Section 6.2, and 

e CC area has byte 3 equal to OFh (only read access granted), and 

e The data area contains an NDEF Message TLV, and 


e The length field of the NDEF Message TLV SHALL be different from zero and equal to the 
actual length of the NDEF message in the value field, and 


e The lock bits related to the memory area of the CC and the NDEF message are in the locked 
state. 


In this state, the memory area is set to read-only (i.e., locked). This process is irreversible because 
setting the appropriate lock bits to 1 performs the transition from READ/WRITE to READ 
ONLY. 

6.4.6 Determination of Life Cycle State 


[RQ T1T NDA 029] Before attempting a read or write operation, the NFC Forum Device in 
NFC Forum Reader/Writer Mode SHALL determine the state of a tag. 


Generally, the most efficient approach is to read the complete tag contents and to buffer the data 
in its memory for analysis and parsing as follows: 


e RID to capture HRO, to qualify it as an NDEF capable tag and to capture UIDO-3 
e RALL using UIDO-3, to capture tag contents into local memory buffer 


e Analyze CC and Lock Status bytes to determine the state 
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6.5 Rules for Life Cycle Operation 


6.5.1 Detect NDEF on tag 


Having determined the Life Cycle State of the tag as described in Section 6.4, the contents of the 
memory buffer SHALL be further analyzed to detect the presence of a valid NDEF message as 
follows: 


1. Ifbyte 0 of block 1 is equal to E1h and byte 1 describes the right version number (see Section 
6.2) and the most significant nibble of byte 3 is equal to Oh, then go to item 2. Otherwise, no 
NDEF data is detected in the Type 1 Tag. 


2. Parse the static data area contents already in memory and read the dynamic memory data 
areas if relevant. 
6.5.2 Read NDEF Message 


The rules for how an NFC Forum Device in NFC Forum Reader/Writer Mode SHALL operate 
for the “read” context are as follows: 


INITIALIZED 
No read of NDEF message is possible. 
READ/WRITE 


The memory contents SHALL be parsed to pass on the NDEF message to the application. If 
relevant, then the dynamic memory data areas SHALL also be read. 


READ ONLY 


The memory contents SHALL be parsed to pass on the NDEF message to the application. If 
relevant, then the dynamic memory data areas SHALL also be read. 


Write NDEF Message 


The rules for how an NFC Forum Device in NFC Forum Reader/Writer Mode SHALL operate 
for the *write" context are as follows: 


e INITIALIZED 
The writing of anew NDEF message SHALL occur as follows: 


e Write NMN = 00h to indicate that no valid NDEF message is present during writing to 
allow error detection in the event that the tag is removed from the field prior to 
completion of operation. 


e Write VNo and RWA if required 

e Write NDEF Message TLV 

e Write NDEF Message data 

e Write NMN = E1h as the last byte to be written 


Type 1 Tag Operation Specification Page 35 


NDEF Detection and NDEF Access 


e READ/WRITE 


The overwriting of a new NDEF message SHALL occur as follows: 


Write NMN = 00h to invalidate an existing NDEF message during writing to allow error 
detection in the event that the tag is removed from the field prior to completion of 
operation. 


Write VNo and RWA if required 

Write NDEF Message TLV 

Write NDEF Message data 

Write NMN = E1h as the last byte to be written 


e READ ONLY 


Write of NDEF message is not possible. 
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A.1 Example NDEF Mapping (Static Memory Model) 


The contents of A.1 are only considered to be informative. 


Appendix A 


The following example NDEF message, which is copied from the Smartposter RTD draft 
specification document, has a total length of 23 bytes (=17h). 


Table 16: Example Smartposter NDEF Message 


Offset Content Length Explanation 
0 OxD1 1 NDEF header. TNF = 0x01 (Well Known Type). 
SR=1, MB=1, ME=1 
1 0x02 1 Record name length (2 bytes) 
2 0x12 1 Length of the Smart Poster data (18 bytes) 
3 “Sp” 2 The record name 
5 OxD1 1 NDEF header. TNF = 0x01, SR=1, MB-1, ME-1 
6 0x01 1 Record name length (1 byte) 
7 OxOE 1 The length of the URI payload (14 bytes) 
8 “U” 1 Record type: “U” 
9 0x01 1 Abbreviation: “http://www.” 
10 “nfc-forum.org” 13 The URI itself. 


After mapping onto the NFC Forum Type 1 Tag, the example NDEF message of Table 16 would 
look like the memory map of Figure 10 below. 
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EEPROM Memory Map 


Byte-3 Byte-4 Byte-5 Lockable 


UID-3 UID-4 UID-5 Locked 


CC3 NDEF NDEF 
(RWA) Message Message 
=00h TLV TLV 


T=03h L=17h 
OE 


n? 


o 


Terminator 
TLV T=FEh 


Locked 


Figure 10: Memory Map of Example Smartposter NDEF Message 
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A.2 Example NDEF Mapping (Dynamic Memory Model) 


The contents of A.2 are considered to be informative. 


Figure 11 shows an example Type 1 Tag with a dynamic memory of 32 blocks (k=1Fh=31). 


There is no NDEF Message present in this example. 


12h xxh 
EEPROM Memory Map 
Type Block Byte-0 Byte-1 Byte-2 Byte-3 Byte-4 Byte-5 Byte-6 Byte-7 Lockable 
No. (LSB) (MSB) 

UID 0 UID-0 UID-1 UID-2 UID-3 UID-4 UID-5 UID-6 Locked 
Data 1 CCO CC1 CC2 CC3 Lock Lock Lock Lock Yes 

(NMN) (VNo) (TMS) (RWA) ControlT | ControlT | ControlT | ControlT 

=00h =10h =1Fh =00h LV LV LV LV 

T=01h L=03h V0=FO0h V1=10h 

Data 2 Lock Memory Memory Memory Memory Memory Yes 

ControlT | Control ControlT | Control ControlT | Control 

LV TLV LV TLV LV TLV 

V2=33h T=02h L=03h V0-F2h V1-06h V2=03h 
Data 3 Yes 
Data 4 Yes 
Data 5 Yes 
Data 6 Yes 
Data 7 Yes 
Data 8 Yes 
Data 9 Yes 
Data A Yes 
Data B Yes 
Data C Yes 
Reserved D 
Lock/Reserved E LOCK-0 | LOCK-1 | OTP-0 OTP-1 OTP-2 OTP-3 OTP-4 OTP-5 
Lock/Reserved F LOCK-2 LOCK-3 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved 

-0 -1 -2 -3 -4 -5 

Data 10 Yes 
Data 11 Yes 
Data 12 Yes 
Data 13 Yes 
Data 14 Yes 
Data 15 Yes 
Data 16 Yes 
Data 17 Yes 
Data 18 Yes 
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EEPROM Memory Map 


Byte-2 Byte-3 Byte-4 Lockable 


Figure 11: Example Dynamic Memory Map 


The tag is in INITIALIZED state and the main memory area is set as following: 
e All lock bits are set to Ob: Lock0 = Lock1 = Lock2 = Lock3 = 00h 
e The CC is set as follows: 

e CCO = 00h to indicate that NDEF data is not present 


e CCI1 = 10h to indicate support of the version 1.0 (major number 1h, minor number Oh) of 
this operation document 


e CC2- 1Fh to indicate 32 blocks or 256 bytes of memory size 
e CC3 = 00h to indicated read and write access granted without any security 
e The data area contains four TLV blocks in the following order: 
e Lock Control TLV: 
T - 01h 
L = 03h 


V = FO 10 33h indicates that each lock bit locks 1 page, each page is 8 bytes, and the lock 
area is 16 bits long, starting at the byte address 120 as calculated by the formula; 


ByteAddr = PageAddr*2P"*"*"** + ByteOffset = 15 * 2? + 0 = 120 where: 
e Position = FOh contains PageAddr = Fh = 15 and ByteOffset = Oh 
e Size = 10h = 16 bits 


e PageControl = 33h contains BytesPerPage = 3h (2° = 8 bytes) and 
BytesLockedPerLockBit = 3h (2° = 8 bytes). 
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e Reserved Memory Control TLV: 
T=02h 
L=03h 


V = F20603h indicates that the reserved area is 6 bytes long starting at the byte address 
122 as calculated by the formula; 


ByteAddr = PageAddr*2P"*"*"** + ByteOffset = 15 * 2? + 2 = 122 


where: 
e Position = F2h contains PageAddr = Fh = 15 and ByteOffset = 2h 
e Size = 06h 


e  PageControl = 03h contains BytesPerPage = 3h, as the least significant nibble. 


The most significant nibble is ignored 
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Revision History 


The following table outlines the revision history of Type 1 Tag Operation Specification. 
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